home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / rexx / imc / rexx-imc.5 / rexx.info < prev    next >
Encoding:
Text File  |  1993-06-20  |  32.8 KB  |  883 lines

  1.   
  2.   The REXX Tutorial for Complete Beginners
  3.  
  4.   Note: some of the information in this file is Unix specific, though most
  5.   of it pertains to every implementation of Rexx. Lines containing
  6.   implementation-specific information are flagged in column 1 with "U" for
  7.   Unix.
  8.   
  9. U More advanced information can be found in rexx.summary (bare details of
  10. U each command and builtin function, with a list of differences from
  11. U standard Rexx) and rexx.ref (technical details of every aspect of this
  12. U Rexx implementation).
  13.   
  14.   1. Creating a Rexx program
  15.   
  16.   Many programmers start by writing a program which displays the message
  17.   "Hello world!".  Here is how to do that in Rexx...
  18.   
  19. U Write a file called "hello.exec" containing the following text.  Use any
  20. U text editor or simply `cat' the text into the file (the text, as with all
  21.   example text in this guide, starts at the first indented line and ends at
  22.   the last.  The four spaces at the start of each line of text should not be
  23.   entered):
  24.   
  25.       /* This program says "Hello world!" */
  26.       say "Hello world!"
  27.   
  28.   This program consists of a comment saying what the program does, and an
  29.   instruction which does it.  "say" is the Rexx instruction which displays
  30.   data on the terminal.
  31.   
  32.   The method of executing a Rexx program varies greatly between
  33. U implementations.  Here is how you execute that file using REXX/imc:
  34.  
  35. U     /mclab/imc/misc/rexx hello
  36.  
  37. U Notes about this command: /mclab/imc/misc/rexx is the path name of the
  38. U interpreter (more accurately, it is the path name of a short script which
  39. U finds the sun3 or sun4 version of the interpreter as appropriate).  If you
  40. U have the directory /mclab/imc/misc in your PATH variable, or if you make a
  41. U symbolic link to /mclab/imc/misc/rexx called "rexx" in your directory,
  42. U then you only need to type "rexx hello".
  43.  
  44. U The word "hello" which comes after the command "rexx" is the name of your
  45. U program.  Ordinarily, the interpreter adds ".exec" to the name you give in
  46. U order to construct the name of the file to execute.  
  47.  
  48.   When you execute your first Rexx program using the method detailed above,
  49.   you should see the message "Hello world!" appear on the screen.
  50.  
  51.   2. Doing arithmetic
  52.  
  53.   Rexx has a wide range of arithmetic operators, which can deal with very
  54.   high precision numbers.  Here is an example of a program which does
  55.   arithmetic.  Make a file called "arith.exec" containing the following:
  56.  
  57.       /* This program inputs a number and does some calculations on it */
  58.       pull a
  59.       b=a*a
  60.       c=1/a
  61.       d=3+a
  62.       e=2**(a-1)
  63.       say 'Results are:' a b c d e
  64.  
  65. U Run it with "/mclab/imc/misc/rexx arith" (or simply "rexx arith") and type
  66.   in a positive integer.  Here is a sample run:
  67.  
  68. U     rexx arith
  69.       5
  70.       Results are: 5 25 0.2 8 16
  71.  
  72.   The results you see are the original number (5), its square (25), its
  73.   reciprocal (0.2), the number plus three (8) and two to the power of one
  74.   less than the number (16).
  75.  
  76.   This example illustrates several things:
  77.  
  78.   * variables: in this example a, b, c, d and e are variables. You can
  79.     assign a value to a variable by typing its name, "=", and a value, and
  80.     you can use its value in an expression simply by typing its name.
  81.   * input: by typing "pull a" you tell the interpreter to ask the user for
  82.     input and to store it in the variable a.
  83.   * arithmetic: the usual symbols (+ - * /) as well as ** (to-power) were
  84.     used to perform calculations.  Parentheses (or "brackets") were used to
  85.     group together an expression, as they are in mathematics.
  86.   * string expressions: the last line of the program displays the results by
  87.     saying the string expression
  88.     
  89.         'Results are:' a b c d e
  90.  
  91.     This has six components: the string constant 'Results are:' and the five
  92.     variables. These components are attached together with spaces into one
  93.     string expression, which the "say" command then displays on the
  94.     terminal.  A string constant is any sequence of characters which starts
  95.     and ends with a quotation mark - that is, either " or ' (it makes no
  96.     difference which you use, as long as they are both the same).
  97.  
  98.   If you supply the number 6 as input to the program, you should notice that
  99.   the number 1/6 is given to nine significant figures.  You can easily
  100.   change this.  Edit the program and insert before the second line:
  101.  
  102.       numeric digits 25
  103.  
  104.   If you run this new program you should see that 25 significant figures are
  105.   produced.  In this way you can calculate numbers to whatever accuracy you
  106.   require, within the limits of the machine.
  107.  
  108.   At this point it seems worth a mention that you can put more than one
  109.   instruction on a line in a Rexx program. You simply place a semicolon
  110.   between the instructions, like this:
  111.  
  112.       /* This program inputs a number and does some calculations on it */
  113.       pull a; b=a*a; c=1/a; d=3+a; e=2**(a-1); say 'Results are:' a b c d e
  114.  
  115.   Needless to say, that example went a bit over the top...
  116.       
  117.   3. Errors
  118.  
  119.   Suppose you ignored the instructions of the previous section and typed a
  120.   non-integer such as 3.4 as input to the program.  Then you would get an
  121.   error, because the ** (to-power) operator is only designed to work when
  122.   the second parameter (that is, the power number) is an integer. You might
  123.   see this, for example:
  124.  
  125.       rexx arith
  126.       3.4
  127.           6 +++ e=2**(a-1)
  128. U     Error 26 running arith.exec, line 6: Invalid whole number
  129.  
  130.   Or if you typed zero, you might see the following (because you cannot
  131.   divide by zero):
  132.  
  133.       rexx arith
  134.       0
  135.           4 +++ c=1/a
  136. U     Error 42 running arith.exec, line 4: Arithmetic overflow or underflow
  137.  
  138.   Perhaps most interestingly, if you type a sequence of characters which is
  139.   not a number, you might see this.  It does not complain about the
  140.   characters you entered, but at the fact that the program tries to use it
  141.   as a number.
  142.  
  143.       rexx arith
  144.       hello
  145.           3 +++ b=a*a
  146. U     Error 41 running /tmp/arith.exec, line 3: Bad arithmetic conversion
  147.  
  148.   In each case, you have generated a "syntax error" (it is classified as a
  149.   syntax error, even though the problem was not directly related to the
  150.   program's syntax).  What you see is a "traceback" starting with the line
  151.   which caused the error (no other lines are listed in this traceback,
  152.   because we have not yet considered any Rexx control structures), and a
  153.   description of the error.  This information should help you to determine
  154.   where the error occurred and what caused it.  More difficult errors can be
  155.   traced with the "trace" instruction (see later).
  156.  
  157.   4. Untyped data
  158.  
  159.   In the previous section, you found that you could input either a number or
  160.   a sequence of letters and store it in the variable a, although arithmetic
  161.   can only be performed on numbers.  That is because data in Rexx are
  162.   untyped.  In other words, the contents of a variable or the result of an
  163.   expression can be any sequence of characters.  What those characters are
  164.   used for matters only to you, the programmer.  However, if you try to
  165.   perform arithmetic on a random sequence of characters you will generate a
  166.   syntax error, as shown in the previous section.
  167.  
  168.   You have seen that you can add strings together by placing a space in
  169.   between them.  There are two other ways: the abuttal and the concatenation
  170.   operator.  An abuttal is simply typing the two pieces of data next to each
  171.   other without a space.  This is not always appropriate: for example you
  172.   cannot type an "a" next to a "b", because that would give "ab", which is
  173.   the name of another unrelated variable.  Instead, it is safer to use the
  174.   concatenation operator, ||.  Both these operations concatenate the strings
  175.   without a space in between. For example:
  176.  
  177.       /* demonstrates concatenation and the use of untyped data */
  178.       a='A string'
  179.       b='123'
  180.       c='456'
  181.       d=a":" (b||c)*3
  182.       say d
  183.  
  184.   The above program says "A string: 370368".  This is because (b||c) is the
  185.   concatenation of strings b and c, which is "123456".  That sequence of
  186.   characters happens to represent a number, and so it can be multiplied by 3
  187.   to give 370368.  Finally, that is added with a space to the concatenation
  188.   of a with ":" and stored in d.
  189.  
  190.   5. More on variables
  191.  
  192.   The previous examples only used single-letter variable names.  In fact it
  193.   is more useful to have whole words as variable names, and Rexx allows this
  194.   up to an implementation maximum (which should be suitably large, e.g. 250
  195.   characters).  Moreover, not only letters but numbers and the six characters
  196.   "@#$!?_" are allowed in variable names - or "symbols", as they are called
  197.   in the liturature.  These are valid symbols:
  198.  
  199.       fred
  200.       Dan_Yr_0gof
  201.       HI!
  202.  
  203.   The case of letters is unimportant, so that for example "Hello", "HELLO"
  204.   and "hellO" all mean the same.
  205.  
  206.   If you use a symbol in an expression when it has not been previously given
  207.   a value, that does not cause an error (unless "signal on novalue" is set -
  208.   see later).  Instead, it just results in its own name translated into
  209.   upper case.
  210.  
  211.       /* A demonstration of simple symbols */
  212.       foo=3
  213.       bar="Characters"
  214.       say foo bar':' hi!
  215.  
  216.   This program says "3 Characters: HI!".
  217.  
  218.   As well as "simple symbols", which are variables like the above, there are
  219.   arrays.  Any ordinary variable name can also be used as the name of an
  220.   array:
  221.  
  222.       /* This program uses an array. */
  223.       pull a
  224.       array.1=a
  225.       array.2=a*a
  226.       array.3=a**3
  227.       say array.1 array.2 array.3 array.1+array.2+array.3
  228.  
  229.   An element of an array is accessed by typing the array name, a dot, and
  230.   the element number.  The array name and the dot are together known as the
  231.   "stem" of the array.  The name of the element is called a "compound
  232.   symbol".  Note that an array does not have to be declared before it is
  233.   used.
  234.  
  235.   In fact not only numbers, but strings and variable names may be used as
  236.   element names.  Also, an element name can consist of two or more parts
  237.   separated by dots, so giving two or more dimensional arrays.
  238.  
  239.       /* This program uses an array with various elements */
  240.       book.1.author="M. F. Cowlishaw"
  241.       book.1.title="The REXX Language, a practical approach to programming"
  242.       book.1.pub="Englewood Cliffs 1985"
  243.       book.2.author="A. S. Rudd"
  244.       book.2.title="Practical Usage of REXX"
  245.       book.2.pub="Ellis Horwood 1990"
  246.       /* insert lots more */
  247.       say "Input a book number"
  248.       pull i
  249.       say "Author:   " book.i.author
  250.       say "Title:    " book.i.title
  251.       say "Publisher:" book.i.pub
  252.  
  253.   In the above program, an array called "book" is created, containing a
  254.   number of records each with elements AUTHOR, TITLE and PUB.  Notice that
  255.   these three uppercase names are produced by symbols "author", "title" and
  256.   "pub", because those symbols have not been given values.  When a book
  257.   number i has been input, the elements of the ith record are printed out.
  258.  
  259.   It is not an error to reference an undefined element of an array.  If you
  260.   type "3" into the above program, you will see this:
  261.  
  262.       Input a book number
  263.       3
  264.       Author:    BOOK.3.AUTHOR
  265.       Title:     BOOK.3.TITLE
  266.       Publisher: BOOK.3.PUB
  267.  
  268.   As before, if a compound symbol has not been given a value, then its name
  269.   is used instead.
  270.  
  271.   There is a way to initialise every element of an array: by assigning a
  272.   value to the stem itself.  Edit the above program and insert after the
  273.   comment line:
  274.  
  275.       book.="Undefined"
  276.  
  277.   This gives every possible element of the array the value "Undefined", so
  278.   that if you again type "3" you will see the following:
  279.  
  280.       Input a book number
  281.       3
  282.       Author:    Undefined
  283.       Title:     Undefined
  284.       Publisher: Undefined
  285.       
  286.   6. Functions
  287.  
  288. U The Rexx Summary contains a list of the functions which are available in
  289.   Rexx.  Each of these functions performs a specific operation upon the
  290.   parameters. For example,
  291.  
  292.       /* Invoke the date function with various parameters */
  293.       say date("W")',' date()
  294.  
  295.   This might say, for example, "Friday, 22 May 1992".
  296.  
  297.   A function is called by typing its name immediately followed by "(". After
  298.   that come the parameters, if any, and finally a closing ")".  In the above
  299.   example, the "date" function is called twice.  The value of date("W") is
  300.   the name of the weekday, and the value of date() is the date in "default"
  301.   format.
  302.  
  303.   7. Conditionals
  304.  
  305.   It is time to use some Rexx control structures.  The first of these will
  306.   be the conditional.  Here is an example:
  307.  
  308.       /* Use a conditional to tell whether a number is less than 50 */
  309.       pull a
  310.       if a<50 then say a "is less than 50"
  311.       else say a "is not less than 50"
  312.  
  313.   The program is executed in the manner in which it reads - so, if a is less
  314.   than 50 then the first instruction is executed, else the second
  315.   instruction is executed.
  316.  
  317.   The "a<50" is a conditional expression.  It is like an ordinary
  318.   expression (in fact conditional expressions and ordinary numeric
  319.   expressions are interchangeable), but it contains a comparison operator.
  320.  
  321.   There are many comparison operators, as follows:
  322.  
  323.   = (equal to)  < (less than)  > (greater than)  <= (less or equal)
  324.   >= (greater or equal)  <> (greater or less)  \= (not equal)
  325.   \> (not greater)  \< (not less)
  326.  
  327.   All the above operators can compare numbers, deciding whether one is equal
  328.   to, less than, or greater than the other.  They can also compare
  329.   non-numeric strings, first stripping off leading and trailing blanks.
  330.  
  331.   There are analogous comparison operators to these for comparing strings
  332.   strictly.  The main difference between them is that 0 is equal to 0.0,
  333.   numerically speaking, but the two are different if compared as strings.
  334.   The other difference is that the strict operators do not strip blanks
  335.   before comparing.  The strict operators are
  336.  
  337.   == (equal to)  << (less than)  >> (greater than)  <<= (less or equal)
  338.   >>= (greater or equal)  \== (not equal)  \>> (not greater)  \<< (not less)
  339.  
  340.   Conditional expressions may be combined with the boolean operators:
  341.   & (and), | (or) and && (xor).  They may also be reversed with the \ (not)
  342.   operator.
  343.  
  344.       /* Decide what range a number is in */
  345.       pull a
  346.       if a>0 & a<10 then say "1-9"
  347.       if a\<10 & a<20 then say "10-19"
  348.       if \ (a<20 | a>=30) then say "20-29"
  349.       if a<=0 | a>=30 then say "Out of range"
  350.  
  351.   As well as demonstrating the boolean and comparison operators, this
  352.   program shows that the "else" clause is not required to be present.
  353.  
  354.   The above program may also be written using Rexx's other conditional
  355.   instruction, "select":
  356.  
  357.       /* Decide what range a number is in */
  358.       pull a
  359.       select
  360.          when a>0 & a<10 then say "1-9"
  361.      when a\<10 & a<20 then say "10-19"
  362.      when \ (a<20 | a>=30) then say "20-29"
  363.      otherwise say "Out of range"
  364.       end
  365.  
  366.   The "select" instruction provides a means of selecting precisely one from
  367.   a list of conditional instructions, with the option of providing a list of
  368.   instructions to do when none of the above were true.  The difference is
  369.   that if no part of a "select" instruction can be executed then a syntax
  370.   error results, whereas it is OK to miss out the "else" part of an "if"
  371.   instruction.
  372.  
  373.   Only one instruction may be placed after "then", "else" and "when", but
  374.   Rexx provides a way of bracketing instructions together so that they can
  375.   be treated as a single instruction.  To do this, place the instruction
  376.   "do" before the list of instructions and "end" after it.
  377.  
  378.       /* execute some instructions conditionally */
  379.       pull a
  380.       if a=50 then
  381.          do
  382.             say "Congratulations!"
  383.         say "You have typed the correct number."
  384.      end
  385.       else say "Wrong!"
  386.  
  387.   If you wish for one of the conditional instructions to do "nothing", then
  388.   you must use the instruction "nop" (for "no operation").  Simply placing
  389.   no instructions after the "then", "else" or "when" will not work.
  390.  
  391.   8. Loops
  392.  
  393.   Rexx has a comprehensive set of instructions for making loops, using the
  394.   words "do" and "end" which you met briefly in the previous section.
  395.  
  396.     a. Counted loops
  397.  
  398.     The instructions within a counted loop are executed the specified number
  399.     of times:
  400.  
  401.         /* Say "Hello" ten times */
  402.     do 10
  403.        say "Hello"
  404.         end
  405.  
  406.     A variation of the counted loop is one which executes forever:
  407.  
  408.         /* This program goes on forever until the user halts it */
  409.     do forever
  410.        nop
  411.     end
  412.  
  413.     b. Control loops
  414.  
  415.     Control loops are like counted loops, but they use a variable (called
  416.     the control variable) as a counter.  The control variable may count
  417.     simply in steps of 1:
  418.  
  419.         /* Count to 20 */
  420.     do c=1 to 20
  421.        say c
  422.     end
  423.  
  424.     or in steps of some other value:
  425.  
  426.         /* Print all multiples of 2.3 not more than 20 */
  427.     do m=0 to 20 by 2.3
  428.        say m
  429.     end
  430.  
  431.     It may take a specific number of steps:
  432.  
  433.         /* Print the first six multiples of 5.7 */
  434.     do m=0 for 6 by 5.7
  435.        say m
  436.     end
  437.  
  438.     or it may go on forever:
  439.  
  440.         /* Print all the natural numbers */
  441.     do n=0
  442.        say n
  443.     end n
  444.  
  445.     The "n" at the end of this last example is optional.  At the end of any
  446.     controlled loop, the name of the control variable may be placed after
  447.     the "end", where it will be checked to see if it matches the control
  448.     variable.
  449.  
  450.     c. Conditional loops
  451.  
  452.     A set of instructions may be executed repeatedly until some condition is
  453.     true. For example,
  454.  
  455.         /* I won't take no for an answer */
  456.     do until answer \= "NO"
  457.        pull answer
  458.         end
  459.  
  460.     Alternatively, they may be executed as long as some condition is true:
  461.  
  462.         /* It's OK to repeat this as long as there is no error */
  463.     do while error=0
  464.        pull a
  465.        if a="ERROR" then error=1
  466.        else say a
  467.     end
  468.  
  469.     Note that in this example, if there is already an error to start with
  470.     then the set of instructions will not be executed at all.  However in
  471.     the previous example the instructions will always be executed at least
  472.     once.
  473.  
  474.     d. Controlled conditional loops
  475.  
  476.     It is possible to combine forms a or b with form c mentioned above, like
  477.     this:
  478.  
  479.         /* I won't take no for an answer unless it is typed three times */
  480.     do 3 until answer \= "NO"
  481.        pull answer
  482.     end
  483.  
  484.     or this:
  485.  
  486.         /* input ten answers, but stop when empty string is entered */
  487.     do n=1 to 10 until ans==""
  488.        pull ans
  489.        a.n=ans
  490.     end
  491.  
  492.   The "iterate" and "leave" instructions allow you to continue with, or to
  493.   leave, a loop respectively.  For example:
  494.  
  495.       /* input ten answers, but stop when empty string is entered */
  496.       do n=1 to 10
  497.          pull a.n
  498.      if a.n=="" then leave
  499.       end
  500.  
  501.       /* print all integers from 1-10 except 3 */
  502.       do n=1 to 10
  503.          if n=3 then iterate
  504.      say n
  505.       end
  506.  
  507.   If a symbol is placed after the instructions "iterate" or "leave", then
  508.   you can iterate or leave the loop whose control variable is that symbol.
  509.  
  510.       /* Print pairs (i,j) where 1 <= i,j <= 5, except (2,j) if j>=3 */
  511.       do i=1 to 5
  512.          do j=1 to 5
  513.         if i=2 & j=3 then iterate i /* or "leave j" would work,
  514.                                        or just "leave"           */
  515.             say "("i","j")"
  516.      end
  517.       end
  518.  
  519.   9. Parsing
  520.  
  521.   The following program examines its arguments:
  522.  
  523.       /* Parse the arguments */
  524.       parse arg a.1 a.2 a.3 a.4 .
  525.       do i=1 to 4
  526.          say "Argument" i "was:" a.i
  527.       end
  528.  
  529.   Execute it as usual, except this time type "alpha beta gamma delta" after
  530.   the program name on the command line, for example:
  531.  
  532. U     rexx arguments alpha beta gamma delta
  533.  
  534.   The program should print out:
  535.  
  536.       Argument 1 was: alpha
  537.       Argument 2 was: beta
  538.       Argument 3 was: gamma
  539.       Argument 4 was: delta
  540.  
  541.   The argument "alpha beta gamma delta" has been parsed into four
  542.   components.  The components were split up at the spaces in the input.  If
  543.   you experiment with the program you should see that if you do not type
  544.   four words as arguments then the last components printed out are empty, and
  545.   that if you type more than four words then the last component contains all
  546.   the extra data.  Also, even if multiple spaces appear between the words,
  547.   only the last component contains spaces.  This is known as "tokenisation".
  548.  
  549.   It is not only possible to parse the arguments, but also the input.  In
  550.   the above program, replace "arg" by "pull".  When you run this new program
  551.   you will have to type in some input to be tokenised.
  552.  
  553.   Replace "parse" with "parse upper" in the program.  Now, when you supply
  554.   input to be tokenised it will be uppercased.
  555.  
  556.   "arg" and "pull" are, respectively, abbreviations for the instructions
  557.   "parse upper arg" and "parse upper pull".  That explains why the "pull"
  558.   instruction appeared in previous examples, and why it was that input was
  559.   always uppercased if you typed letters in response to it.
  560.  
  561.   Other pieces of data may be parsed as well.  "parse source" parses
  562.   information about how the program was invoked, and what it is called.
  563.   "parse version" parses information about the interpreter itself.  However,
  564.   the two most useful uses of the parse instruction are
  565.   "parse var [variable]" and "parse value [expression] with".  These allow
  566.   you to parse arbitrary data supplied by the program.
  567.  
  568.   For example,
  569.  
  570.       /* Get information about the date and time */
  571.       d=date()
  572.       parse var d  day month year
  573.  
  574.       parse value time() with hour ':' min ':' sec
  575.  
  576.   The last line above illustrates a different way to parse data.  Instead of
  577.   tokenising the result of evaluating time(), we split it up at the
  578.   character ':'.  Thus, for example, "17:44:11" is split into 17, 44 and 11.
  579.  
  580.   Any search string may be specified in the "template" of a "parse"
  581.   command.  The search string is simply placed in quotation marks, for
  582.   example:
  583.  
  584.       parse arg first "beta" second "delta"
  585.  
  586.   This line assigns to variable first anything which appears before
  587.   "beta", and to second anything which appears between "beta" and "delta".
  588.   If "beta" does not appear in the argument string, then the entire string
  589.   is assigned to first, and the empty string is assigned to "second".  If
  590.   "beta" does appear, but "delta" does not, then everything after "beta"
  591.   will be assigned to second.
  592.  
  593.   It is possible to tokenise the pieces of input appearing between search
  594.   strings. For example,
  595.  
  596.       parse arg "alpha" first second "delta"
  597.  
  598.   This tokenises everything between "alpha" and "delta" and places the
  599.   tokens in first and second.
  600.  
  601.   Placing a dot instead of a variable name during tokenising causes that
  602.   token to be thrown away:
  603.  
  604.       parse pull a . c . e
  605.  
  606.   This keeps the first, third and last tokens, but throws away the second
  607.   and fourth.  It is often a good idea to place a dot after the last
  608.   variable name, thus:
  609.  
  610.       parse pull first second third .
  611.  
  612.   Not only does this throw away the unused tokens, but it also ensures that
  613.   none of the tokens contain spaces (remember, only the last token may
  614.   contain spaces; this is the one we are throwing away).
  615.  
  616.   Finally, it is possible to parse by numeric position instead of by
  617.   searching for a string.  Numeric positions start at 1, for the first
  618.   character, and range upwards for further characters.
  619.  
  620.       parse var a 6 piece1 +3 piece2 +5 piece3
  621.  
  622.   The value of piece1 will be the three characters of a starting at
  623.   character 6; piece2 will be the next 5 characters, and piece3 will be the
  624.   rest of a.
  625.  
  626.   
  627.   10. Interpret
  628.  
  629.   Suppose you have a variable "inst" which contains the string "a=a+1".  You
  630.   can execute that string as an instruction, by typing:
  631.  
  632.       interpret inst
  633.  
  634.   The interpret instruction may be used to accept Rexx instructions from the
  635.   user, or to assign values to variables whose names are not known in
  636.   advance.
  637.  
  638.       /* Input the name of a variable, and set that variable to 42 */
  639.       parse pull var
  640.       interpret var "=" 42
  641.  
  642.   11. The stack
  643.  
  644.   Rexx has a data stack, which is accessed via the "push", "queue" and
  645.   "pull" instructions.  The "pull" instruction (or in full, "parse pull")
  646.   inputs data from the user as we have seen before.  However, if there is
  647.   some data on the stack then it will pull that instead.
  648.  
  649.       /* Access the Rexx stack */
  650.       queue "Hello!"
  651.       parse pull a      /* a contains "Hello!" */
  652.       parse pull b      /* b is input from the user */
  653.       push "67890"
  654.       push "12345"
  655.       parse pull c      /* c contains "12345" */
  656.       /* there is one item left on the stack */
  657.  
  658.   The difference between "push" and "queue" is that when the items are
  659.   pulled off the stack, the items which were queued appear in the same order
  660.   that they were queued (FIFO, or first in, first out), and the items which
  661.   were pushed appear in reverse order (LIFO, or last in, first out).
  662.  
  663.   12. Subroutines and functions
  664.  
  665.   The following program defines an internal function, and calls it with
  666.   some data:
  667.  
  668.       /* Define a function */
  669.       say "The results are:" square(3) square(5) square(9)
  670.       exit
  671.  
  672.       square: /* function to square its argument */
  673.       parse arg in
  674.       return in*in
  675.  
  676.   The output from this program should be: "The results are: 9 25 81"
  677.  
  678.   When Rexx finds the function call "square(3)", it searches the program for
  679.   a label called "square".  It finds the label on line 5 - the name followed
  680.   by a colon.  The interpreter executes the code which starts at that line,
  681.   until it finds the instruction "return".  While that code is being
  682.   executed, the arguments to the function can be determined with "parse arg"
  683.   in the same way as the arguments to a program.  When the "return"
  684.   instruction is reached, the value specified is evaluated and used as the
  685.   value of "square(3)".
  686.  
  687.   The "exit" instruction in this program causes it to finish executing
  688.   instead of running into the function.
  689.  
  690.   A function which takes multiple arguments may be defined, simply by
  691.   separating the arguments with a comma. That is, like this:
  692.  
  693.       /* Define a function with three arguments */
  694.       say "The results are:" condition(5,"Yes","No") condition(10,"X","Y")
  695.       exit
  696.  
  697.       condition: /* if the first argument is less than 10, return the second,
  698.                     else return the third. */
  699.       parse arg c,x,y
  700.       if c<10 then return x
  701.       else return y
  702.  
  703.   A subroutine is similar to a function, except that it need not give a
  704.   value after the "return" instruction.  It is called with the "call"
  705.   instruction.
  706.  
  707.       /* Define a subroutine to print a string in a box, then call it */
  708.       call box "This is a sentence in a box"
  709.       call box "Is this a question in a box?"
  710.       exit
  711.   
  712.       box: /* Print the argument in a box */
  713.       parse arg text
  714.       say "+--------------------------------+"
  715.       say "|"centre(text,32)"|"             /* centre the text in the box */
  716.       say "+--------------------------------+"
  717.       return
  718.  
  719.   It is possible to call a function, even a built-in function, as if it were
  720.   a subroutine.  The result returned by the function is placed into the
  721.   variable called "result".
  722.  
  723.       /* print the date, using the "call" instruction */
  724.       call date "N"
  725.       say result
  726.  
  727.   If a function or subroutine does not need to use the variables which the
  728.   caller is using, or if it uses variables which the caller does not need,
  729.   then you can start the function with the "procedure" instruction.  This
  730.   clears all the existing variables away out of sight, and prepares for a
  731.   new set of variables.  This new set will be destroyed when the function
  732.   finishes executing.  The following program calculates the factorial of a
  733.   number recursively:
  734.  
  735.       /* Calculate factorial x, that is, 1*2*3* ... *x  */
  736.       parse pull x .
  737.       say x"!="factorial(x)
  738.       exit
  739.  
  740.       factorial: /* calculate the factorial of the argument */
  741.       procedure
  742.       parse arg p
  743.       if p<3 then return p
  744.       else return factorial(p-1) * p
  745.  
  746.   The variable p which holds the argument to funtion factorial is unaffected
  747.   during the calculation of factorial(p-1), because it is hidden by the
  748.   "procedure" instruction.
  749.  
  750.   If the subroutine or function needs access to just a few variables, then
  751.   you can use "procedure expose" followed by the list of variable names to
  752.   hide away all except those few variables.
  753.  
  754.   You can write functions and subroutines which are not contained in the
  755.   same Rexx program.  In order to do this, write the function and save it
  756.   into a file whose name will be recognised by the interpreter.  This type
  757.   of function is called an "external" function, as opposed to an "internal"
  758.   function which can be found inside the currently running program.
  759.  
  760.   If you want to call your function or subroutine using "call foobar" or
  761. U "foobar()", then you should save it in a file named "foobar.exec" which
  762. U can be found in the current directory or in your path.
  763.  
  764.   The "procedure" instruction is automatically executed before running your
  765.   external function, and so it should not be placed at the start of the
  766.   function.  It is not possible for an external function to access any of
  767.   its caller's variables, except by the passing of parameters.
  768.  
  769.   For returning from external functions, as well as the "return" instruction
  770.   there is "exit".  The "exit" instruction may be used to return any data to
  771.   the caller of the function in the same way as "return", but "exit" can be
  772.   used return to the caller of the external function even when it is used
  773.   inside an internal function (which is in turn in the external function).
  774.   "exit" may be used to return from an ordinary Rexx program, as we have
  775.   seen.  In this case, a number may be supplied after "exit", which will be
  776.   used as the exit code of the interpreter.
  777.  
  778.   13. Executing commands
  779.  
  780.   Rexx can be used as a control language for a variety of command-based
  781.   systems.  The way that Rexx executes commands in these systems is as
  782.   follows.  When Rexx encounters a program line which is nether an
  783.   instruction nor an assignment, it treats that line as a string expression
  784.   which is to be evaluated and passed to the environment.  For example:
  785.  
  786.       /* Execute a given command upon a set of files */
  787.       parse arg command
  788.       command "file1"
  789.       command "file2"
  790.       command "file3"
  791.       exit
  792.  
  793.   Each of the three similar lines in this program is a string expression
  794.   which adds the name of a file (contained in the string constants) to the
  795.   name of a command (given as a parameter).  The resulting string is passed
  796.   to the environment to be executed as a command.  When the command has
  797.   finished, the variable "rc" is set to the exit code of the command.
  798.  
  799.   The environment to which a command is given varies widely between systems,
  800.   but in most systems you can select from a set of possible environments by
  801.   using the "address" instruction.
  802.   
  803.   14. Signal
  804.  
  805.   Where other programming languages have the "goto" command, Rexx has
  806.   "signal".  The instruction "signal label" makes the program jump to the
  807.   specified label.  However, once this has been done, it is not possible to
  808.   resume any "select" or "do" control structures that have recently been
  809.   entered.  Thus the main use of "signal" is to jump to an error handling
  810.   routine when something goes wrong, so that the program can clean up and
  811.   exit.
  812.  
  813.   There is a much more useful way of using "signal", however.  That is to
  814.   trap certain kinds of error condition.  The conditions which may be
  815.   trapped include: "syntax" (that is, any syntax error), "error" (any
  816.   environment command that results in a non-zero exit code), "halt" (when
  817.   the user interrrupts execution) and "novalue" (which is when a symbol is
  818.   used without having been given a value).
  819.  
  820.   Error trapping for one of these conditions is turned on by
  821.  
  822.       signal on <condition>
  823.  
  824.   and is turned off by
  825.  
  826.       signal off <condition>
  827.  
  828.   When one of these conditions occurs, the program immediately signals to a
  829.   label whose name is the same as that of the condition.  Trapping is turned
  830.   off, so another "signal on" will be required if you want to continue to
  831.   trap that condition.
  832.  
  833.   Whenever a "signal" occurs, the variable "sigl" is set to the line number
  834.   of the instruction which caused the jump.  If the signal was due to an
  835.   error trap, then the variable "rc" will be set to an error code.
  836.  
  837.       /* This program goes on forever until someone stops it. */
  838. U     say "Press Control-C to halt"
  839.       signal on halt
  840.       do i=1
  841.          say i
  842.      do 10000
  843.      end
  844.       end
  845.  
  846.       halt:
  847.       say "Ouch!"
  848.       say "Died at line" sigl
  849.  
  850.  
  851.   15. Tracing
  852.  
  853. U Full details of how to use Rexx's tracing facility are contained in
  854. U rexx.ref.
  855.  
  856.   If a program goes wrong and you need more information in order to work out
  857.   why, then Rexx provides you with the ability to trace all or part of your
  858.   program to see what is happening.
  859.  
  860.   The most common form of tracing is turned on by
  861.  
  862.       trace r
  863.  
  864.   This causes each instruction to be listed before it is executed. Also, it
  865.   displays the results of each calculation after it has been found.
  866.  
  867.   Another useful trace command is:
  868.  
  869.       trace ?a
  870.  
  871.   This makes the interpreter list each instruction and stop before it is
  872.   executed.  You can execute the instruction by pressing return, or you can
  873.   type in some Rexx to be interpreted, after which the interpreter will
  874.   pause again.  You can use this to examine the program's variables and so
  875.   forth.
  876.  
  877.   If you want the interpreter to stop only when passing a label, use:
  878.  
  879.      trace ?l
  880.  
  881.   This is useful for setting breakpoints in the program, or for making the
  882.   program stop at a function call.
  883.